Une transaction est une unité de travail

Les modifications de données arrivent rarement seules : un virement doit débiter un compte et créditer un autre, et une commande doit réserver du stock et enregistrer un paiement. Si le système s'arrête à mi-chemin, la base de données décrit alors un monde qui n'a jamais existé. Une transaction est la réponse de la base de données à ce problème — une séquence d'une ou plusieurs opérations que la base de données traite comme une unité de travail unique et indivisible.

Tout, ou rien

Au sein d'une transaction, chaque opération appartient à un même résultat. La base de données n'expose jamais un état final dans lequel seule une partie de la transaction a eu lieu. L'illustration classique est un virement entre deux comptes bancaires : réduire le solde du compte source, puis augmenter le solde du compte destinataire. Si seule la première étape réussissait, l'argent disparaîtrait ; si seule la seconde, l'argent apparaîtrait de nulle part. Regrouper les deux étapes dans une seule transaction élimine ces deux possibilités.

Cette garantie du tout ou rien est appelée atomicité. Valider est l'acte qui rend permanentes les modifications de la transaction ; une transaction jamais validée ne laisse aucune trace. Durabilité apporte la pièce finale : une fois la validation effectuée, la modification survit même si la machine perd l'alimentation un instant plus tard.

Une transaction est une frontière

Il est utile de se représenter une transaction comme une frontière tracée autour d'un groupe d'instructions. Avant et après cette frontière, les données satisfont les règles imposées par la structure. À l'intérieur de la frontière, des états intermédiaires existent — un compte est déjà débité alors que l'autre n'est pas encore crédité — mais ces états sont propres à la transaction. Les instructions ultérieures des autres sessions ne les considèrent pas comme la vérité.

Deux rôles à la fois

Les transactions remplissent donc deux rôles. Le premier est la gestion des défaillances: si le processus plante, si la connexion est interrompue ou si une instruction génère une erreur, la base de données peut restaurer l'état qui existait avant le début de la transaction. Le second est le contrôle de la visibilité: pendant que le travail est en cours, les autres lecteurs sont protégés du résultat inachevé. Ces deux rôles sont liés mais non identiques — l'atomicité décide si les modifications sont conservées, tandis que la visibilité est régie par l'isolation, le paramètre qui contrôle dans quelle mesure les transactions concurrentes peuvent se voir mutuellement.

Gardez l'unité sur une seule connexion

L'état de la transaction appartient à une connexion ou à une session, donc l'instruction qui ouvre la transaction et la validation qui la termine doivent s'exécuter sur la même connexion. De nombreux pilotes fonctionnent également en mode autocommit , où chaque instruction constitue sa propre transaction — une unité comportant plusieurs instructions nécessite la désactivation de l'autocommit ou un démarrage explicite.

Une transaction est une unité de travail

Regrouper les deux étapes dans une seule transaction élimine ces deux possibilités. Concepts clés : transaction — une séquence d'une ou plusieurs opérations exécutées comme une unité de travail unique et indivisible.

QUESTION 1

Quelle affirmation décrit le mieux une transaction de base de données ?

Une séquence d'une ou plusieurs opérations traitées comme une unité de travail unique et indivisible.

Un fichier journal qui enregistre chaque instruction que la base de données a exécutée.

Une copie de sauvegarde de la base de données effectuée avant toute modification.

Une seule instruction SQL qui modifie une ligne.

QUESTION 2

Un virement débite le compte source, puis le serveur perd l'alimentation avant l'exécution du crédit. La transaction n'a jamais été validée. Que garantit la base de données lors de son redémarrage ?

Seul le débit est conservé, car il s'est exécuté en premier.

Le débit est conservé et le crédit est réappliqué automatiquement.

Les deux modifications sont conservées mais marquées comme incomplètes.

Aucune des deux modifications ne survit ; la transaction incomplète est annulée lors de la récupération.

QUESTION 3

Quelle est la différence entre COMMIT et ROLLBACK ?

Ce sont des synonymes ; les deux rendent les modifications permanentes.

COMMIT termine l'instruction en cours ; ROLLBACK termine toute la session.

COMMIT rend permanentes les modifications de la transaction ; ROLLBACK les annule et laisse les données telles qu'elles étaient avant le début de la transaction.

COMMIT stocke une copie des données ; ROLLBACK restaure cette copie.

QUESTION 4

Un développeur affirme : « Comme mon virement s'exécute dans une seule transaction, aucune autre session ne peut voir le débit avant le crédit. » Est-ce correct ?

Non, car les autres sessions peuvent toujours voir les données non validées dans toutes les bases de données.

Non ; l'atomicité décide si les modifications sont conservées, tandis que la visibilité est régie par l'isolation, de sorte qu'une autre session peut encore lire des valeurs non validées selon le niveau d'isolation.

Oui ; l'atomicité masque tout état intermédiaire à toutes les autres sessions.

Oui, mais seulement si la transaction est très courte.

QUESTION 5

Un commit se termine avec succès, puis la machine perd l'alimentation un instant plus tard. Que garantit la base de données après la récupération ?

Les modifications validées sont toujours présentes, car la durabilité garantit que les modifications validées survivent aux plantages et aux redémarrages.

Seule la dernière instruction de la transaction survit.

La transaction est automatiquement annulée après le redémarrage.

Les modifications sont perdues parce que la panne de courant a eu lieu avant le prochain point de contrôle.

Étude de cas : le virement interrompu

Lisez le scénario ci-dessous et répondez aux deux questions.

Une application transfère 100 du compte 1 vers le compte 2. Elle exécute START TRANSACTION, puis UPDATE accounts SET balance = balance - 100 WHERE id = 1. Avant que le deuxième UPDATE puisse s'exécuter, la connexion réseau à la base de données est interrompue et le processus de l'application plante. La table accounts possède une contrainte de vérification qui maintient les soldes non négatifs. Au redémarrage, l'application ouvre une nouvelle connexion et ne trouve aucune trace de la réalisation du virement, et les soldes des deux comptes sont exactement tels qu'ils étaient avant la tentative.

Du point de vue de la base de données, qu'advient-il du débit, et quelle garantie l'explique ?

Réponse :
Le débit ne devient jamais un résultat final car la transaction n'a jamais été validée. Une transaction est une unité de travail, et l'atomicité signifie que toute l'unité s'applique ou qu'aucune partie ne s'applique. Lorsque la connexion se termine, la base de données annule la transaction — ou effectue la même annulation lors de la récupération après plantage — en restaurant l'état qui existait avant le début de la transaction. Il n'existe donc aucun état dans lequel 100 a quitté le compte 1 sans arriver sur le compte 2, si bien qu'aucun argent ne disparaît.

L'application est ensuite refactorisée pour utiliser un pool de connexions. Pourquoi le premier UPDATE et le commit doivent-ils s'exécuter sur la même connexion ou session, et quel rôle joue l'autocommit ?

Réponse :
L'état de la transaction appartient à une connexion ou à une session, donc l'instruction qui ouvre la transaction et le commit qui la termine doivent être émis sur la même connexion. Si une couche de mise en pool achemine les instructions ultérieures vers une autre connexion, le commit s'applique à une unité de travail différente et la transaction d'origine reste ouverte ou est annulée à la déconnexion, ce qui rompt la frontière voulue par l'application. L'autocommit importe car la plupart des pilotes fonctionnent par défaut en mode autocommit, où chaque instruction constitue sa propre transaction ; dans ce mode, le débit deviendrait permanent dès son exécution, et aucune unité tout ou rien n'existerait. Une unité comportant plusieurs instructions nécessite donc la désactivation de l'autocommit ou un démarrage explicite de la transaction.